dns 幾乎在現今的網路世界是個基本的存在，沒有它在，如果要上個網都需要輸入一堆 ip ，那真的是會要了我老人家的命。
首先我先用以下指令來看結果 :
dig {domain}
╰─➤ dig hahow.in
; <<>> DiG 9.10.6 <<>> hahow.in
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 38030
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 6
;; QUESTION SECTION:
;hahow.in. IN A
;; ANSWER SECTION:
hahow.in. 1449 IN A 35.229.250.9
;; AUTHORITY SECTION:
hahow.in. 20976 IN NS rodney.ns.cloudflare.com.
hahow.in. 20976 IN NS etta.ns.cloudflare.com.
AUTHORITY SECTION
;; ADDITIONAL SECTION:
rodney.ns.cloudflare.com. 20976 IN A 172.64.33.228
rodney.ns.cloudflare.com. 20976 IN A 173.245.59.228
rodney.ns.cloudflare.com. 20976 IN A 108.162.193.228
etta.ns.cloudflare.com. 20976 IN A 173.245.58.156
etta.ns.cloudflare.com. 20976 IN A 108.162.192.156
etta.ns.cloudflare.com. 20976 IN A 172.64.32.156
;; Query time: 358 msec
;; SERVER: 172.16.0.1#53(172.16.0.1)
;; WHEN: Thu Sep 21 22:03:05 CST 2023
;; MSG SIZE rcvd: 195
整個顯示結果可以分為以下幾個部份 :
QUESTION SECTION : 請求查詢 domain 為 hahow.in 然後是 A record 類型。
ANSWER SECTION : 請求的結果，對應的 ip 為 35.229.250.9。
AUTHORITY SECTION : 就是指該 domain 的 授權服務，從這個結果可以知道為 cloudflare 來。
ADDITIONAL SECTION : 授權服務的實際位置。
它是一種最常見的 dns record 類型，簡單的說就是 ip4 與 domain 的對應，當 client 在 chrome 或啥輸入 hahow.in 時，dns 服務會去查這個 domain 對應的 A record 然後回傳相對應的 ip。
不過注意一下，你有時後 dig 時可能會看到同一個 domain 會有多個 A record，那是因為 load balancing 的關係。
備註 :
ipv6 的 record 類型為 AAAA。
我這裡列出幾個我比較常看到的。
CNAME ( Canonical Name Record ) : 就是把 domain 指到另一個 domain。
TXT ( Text Record ) : 記錄一些文字訊息，通常都是用來驗證要啥的，像一些 SPF、驗證密。
NS ( Name Server Record ) : 用於指定 domain 的 dns 服務，它們負責管理該 domin 的 dns 記錄。
SRV ( Service Record ) : 指定到某個服務的主機名與 port
SOA ( Start of Authority Record ) : 他會記錄某個 dns 區域的相關資訊。
MX ( Mail Exchanger Record ) : email 用的。
假設我有一個 2 個 domain。
hahow.in
h4b.hahow.in
然後整個 record 記錄為
CANME : h4b.hahow.in → hahow.in
A : hahow.in → 111.111.111.111
那這樣有什麼意義呢 ? 為什麼不要 h4b.hahow.in 建個 A record 指定 111.111.111.111 就好呢 ?
因為好管理 :
假設 A record 的 ip 變了，你的 h4b.hahow.in 不用改。
假設子 domain 又多了幾個 h5b.hahow.in、h6b.hahow.in，那這樣你的 ip 改了，你就要去改每一個。
實際應用時，像我們常用的 cdn 就是會需要去將我們的 domain CNAME 連到 cdn 的 domain，就好。
dig {domain} {record type}
dig {domain} ANY
dig -x {ip}
然後這裡發現一個東西，就是首先我用 dig google.com 結果如下 :
╰─➤ dig google.com
; <<>> DiG 9.10.6 <<>> google.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 47047
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 4, ADDITIONAL: 0
;; QUESTION SECTION:
;google.com. IN A
;; ANSWER SECTION:
google.com. 35 IN A 172.217.163.46
;; AUTHORITY SECTION:
google.com. 32637 IN NS ns1.google.com.
google.com. 32637 IN NS ns3.google.com.
google.com. 32637 IN NS ns2.google.com.
google.com. 32637 IN NS ns4.google.com.
;; Query time: 9 msec
;; SERVER: 172.16.0.1#53(172.16.0.1)
;; WHEN: Thu Sep 21 22:59:23 CST 2023
;; MSG SIZE rcvd: 116
然後我再用 answer 裡的 ip 反查，發現它實際上，它並沒有像我預想的會回傳google.com 這個東東回來，而是回了如下的結果46.163.217.172.in-addr.arpa 。
這是因為 ip 172.217.163.46 配置了一個叫PTR 的 record，其中in-addr.apra是在 dns 標準中定義的特殊 domain，用來提到供可靠的反向查詢方法，以下面的範例來看，他可以用 ip 172.217.163.46 反過來的 46.163.217.172.in-addr.arpa 裡找到對應的 domain google.com。
dig -x 172.217.163.46
╰─➤ dig -x 172.217.163.46
; <<>> DiG 9.10.6 <<>> -x 172.217.163.46
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 3473
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 13, ADDITIONAL: 13
;; QUESTION SECTION:
;46.163.217.172.in-addr.arpa. IN PTR
;; ANSWER SECTION:
46.163.217.172.in-addr.arpa. 5237 IN PTR maa05s01-in-f14.1e100.net.
46.163.217.172.in-addr.arpa. 5237 IN PTR tsa01s13-in-f14.1e100.net.
;; AUTHORITY SECTION:
省略
;; Query time: 11 msec
;; SERVER: 172.16.0.1#53(172.16.0.1)
;; WHEN: Thu Sep 21 23:00:25 CST 2023
;; MSG SIZE rcvd: 530
仔細看了一下這些 dns record 才發現 dns 原來可以玩那麼多東西。
iThome鐵人賽
看影片追技術